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(54) A technique for centrally tracking transactions in an electronic billing system 



(57) A method is provided for centrally tracking 
transactions in an electronic billing system. The system 
includes multiple different billing entities, multiple differ- 
ent financial institute entities and multiple different user 
entities. Each of the multiple different billing entities is 
associated with a respective portion of the multiple dif- 
ferent user entities and each of the multiple different fi- 
nancial institute entities is associated with a respective 
portion of the multiple different user entities. A message 
is received from any of the multiple different financial 
institute entities indicating a request from any of the mul- 
tiple different user entities associated with the applica- 
ble financial institute entity to view billing information. 



The receipt of the request to view the billing information 
is logged in a database as first event information. A mes- 
sage indicative of the billing information of at least one 
of the multiple different billing entities associated with 
the applicable user entity which is available for viewing 
is transmitted to the applicable user entity. A message 
indicating a request from the applicable user entity to 
view the available billing information of that billing entity 
is received from any of the at least one of the billing en- 
tities. The receipt of the message indicating the appli- 
cable user entity request to view the billing information 
of the applicable billing entity is logged in the database 
as a second event information. 
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Description 

FIELD OF THE INVENTION 

[0001 J The present invention relates generally to dis- 
tributed data networks and, more particularly, to a dis- 
tributed data accessing technique. 

BACKGROUND OF THE INVENTION 

[0002] There are two prevalent models for electronic 
bill presentment that are currently used in industry. The 
first is an aggregation model 10, which is shown in Fig- 
ure 1. In its simplest form, the aggregation model 10 in- 
cludes a customer 12, an aggregator 14, and a plurality 
of billers 16. The customer 12 can be, for example, an 
individual person, a family, or a business. The aggrega- 
tor 1 4 can be a financial institution (Fl) such as, for ex- 
ample, a bank. Alternatively, the aggregator 14 can be 
a separate entity which acts of behalf of a sponsor 18, 
which can also be an Fl such as a bank. Each biller 16 
can be of any billing institution type such as, for exam- 
ple, a local telephone company, a local electric compa- 
ny, a retail outlet, or a national long distance telephone 
company. 

[0003] Each biller 16 provides customer-related in- 
voice data to the aggregator 14. The aggregator 14 
serves as an intermediary between each biller 16 and 
the customer 12 by providing bill presentment directly 
to the customer 1 2. 

[0004] There are two variants of the aggregation mod- 
el 1 0 resulting from the ownership, or "branding", of the 
presentation experience and the communication chan- 
nel between the aggregator 14 and the customer 12. In 
one variant, the aggregator 14 may offer aggregator- 
branding, thus totally owning both the presentation ex- 
perience and the communication channel between the 
aggregator 14 and the customer 1 2. In the other variant, 
the aggregator 14 may offer sponsor-branding, thus 
staying "behind the scenes" in terms of the presentation 
experience and supporting the communication channel 
between the aggregator 14 and the customer 12. 
[0005] The second prevalent model for electronic bill 
presentment is a biller direct model 20, which is shown 
in Figure 2. In its simplest form, the biller direct model 
20 includes a customer 12 and at least one biller 16. In 
the biller direct model 20, each biller 1 6 retains the cus- 
tomer-related invoice data and the full relationship with 
the customer 12, i.e., the presentation experience and 
the communication channel. The customer 1 2 may have 
software for providing a capability similar to Web brows- 
er bookmarking so as to allow easy navigation between 
billers, and thus some level of virtual aggregation. How- 
ever, there is no actual aggregation such as with the ag- 
gregator 14 of the aggregation model 10 described 
above. 

[0006] The above-described models present a dichot- 
omy between a sponsor-centric view and a biller-centric 



view of bill presentment. That is, the aggregation model 
10 allows the aggregator 14 and/or the sponsor 18 to 
use customer-related invoice data, bill presentment, 
and the communication channel between the aggrega- 

s tor 1 4 and the customer 1 2 for cross-selling or other pe- 
ripheral services. The biller direct model 20, on the other 
hand, insures that control of customer-related invoice 
data, bill presentment, and the communication channel 
between the biller 1 6 and the customer 1 2 remains with 

10 the biller 16. 

[0007] Also, neither of the above-described models 
adopt a truly customer-centric view. That is, neither of 
the above-described models allow a customer 12 to in- 
teract directly with individual billers 16 while retaining 

'5 the benefits of interacting with a single aggregator 14, 
such as the ability to retain a single authentication and 
log-in procedure and a common bill presentation frame- 
work. Further, neitherof the above-described models al- 
low a customer 12 to retain the benefits of interacting 

20 with a single aggregator 14 while allowing the aggrega- 
tor 14, billers 16, and sponsor 18 to retain certain pref- 
erences, such as the ability to retain control of customer- 
related data and a communication channel with each 
customer 12. Accordingly, it would be desirable to pro- 

25 vide a distributed data accessing technique which ad- 
dresses the above-mentioned shortcomings of the 
above-described models. 

OBJECTS OF THE INVENTION 

30 

[0008] One object of the present invention is to pro- 
vide a distributed data accessing technique that allows 
acustomerto interact directly with individual billers while 
retaining the benefits of interacting with a single aggre- 
35 gator. 

[0009] Another object of the present invention is to 
provide a distributed data accessing technique that al- 
lows a customer to retain the benefits of interacting with 
a single aggregator while allowing the aggregator, bill— 
40 ers, and sponsor to retain control of customer-related 
data and a communication channel with each customer. 
[0010] Another object of the present invention is to 
provide a distributed data accessing technique that al- 
lows complete flexibility as to who is offering bill present- 
's ment: billers only, aggregator only, or some combination 
of the above. 

[0011] Another object of the present invention is to 
provide a distributed data accessing technique that sup- 
ports an audit trail which can serve any of a variety of 

so purposes, including improved customer care. 

[001 2] The above-stated objects, as well as other ob- 
jects, features, and advantages, of the present invention 
will become readily apparent from the following detailed 
description which is to be read in conjunction with the 

55 appended drawings. 
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SUMMARY OF THE INVENTION 

[0013] According to the present invention, a distribut- 
ed data accessing technique is realized by storing, at a 
first network station, information identifying data which 
is available at a second network station. The first net- 
work station can be, for example, an electronic payment 
and customer service entity. The second network station 
can be, forexample, a billing entity such as a utility com- 
pany. The information identifying the data that is avail- 
able at the second network station can be, for example, 
information which indicates that a bill is available at the 
second network station. 

[0014] A signal is generated at the first network sta- 
tion. The signal represents the information identifying 
the available data at, and linking information to, the sec- 
ond network station. The linking information can be, for 
example, a web site address along with some additional 
parameters. 

[001 5] The signal is transmitted to a third network sta- 
tion. The third network station can be, for example, a 
user entity such as a personal computer. The transmit- 
ted linking information is operable at the third network 
station to establish a network link over which the iden- 
tified available data is transmittable from the second net- 
workstation to the third network station. That is, the third 
network station can invoke the linking information so as 
to create, for example, a link to the web site of a billing 
entity. 

[0016] The signal is typically generated in response 
to a request for data. Such a request can include an 
identification of a user so that the user can be authenti- 
cated. The signal is then generated after the user is au- 
thenticated. The request is typically received from the 
third network station. The request, as well as any other 
events that occur between the various network stations, 
can be logged at the first network station. The logged 
events can then be accessed by another entity, such as, 
a centralized customer service center, which could be a 
fourth network station. 

[0017] The identified available data is typically stored 
at the second network station. This data could, if de- 
sired, be provided to the second network station by an 
entity located outside of the network, such as a legacy 
billing system or an established billing aggregator. 
[001 8] According to other aspects of the invention, the 
first network station receives a notification that the iden- 
tified available data was transmitted from the second 
network station to the third network station. The identi- 
fied available data is preferably transmitted from the 
second network station directly to the third network sta- 
tion over the network link established between the sec- 
ond and third network stations as discussed above. The 
identified available data can then be transmitted from 
the second network station to the third network station 
so as to be displayed in a presentation format. The pres- 
entation format can be, for example, an internet web 
page or a frame of an internet web page. 
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[0019] Preferably, only a single authentication proce- 
dure is required for a user entity to receive available data 
identifying information and linking information for differ- 
ent data available a different sites, e.g. different bills at 
5 different biller sites. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0020] In order to facilitate a fuller understanding of 
»o the present invention, reference is now made to the ap- 
pended drawings. These drawings should not be con- 
strued as limiting the present invention , but are intended 
to be exemplary only. 

[0021] Figure 1 is an aggregation model for electronic 
is bill presentment. 

[0022] Figure 2 is a biller direct model for electronic 
bill presentment. 

[0023] Figure 3 is an infrastructure diagram of a dis- 
tributed database entity in accordance with the present 
20 invention. 

[0024] Figure4 is a schematic diagram of an electron- 
ic bill presentment and payment system in accordance 
with the present invention. 

[0025] Figure5 is a schematic diagram of an electron- 
25 ic payment and customer service (EPCS) entity in ac- 
cordance with the present invention. 
[0026] Figure 6 is a schematic diagram of the elec- 
tronic bill presentment and payment system shown in 
Figure 4, extendedto include certain associated directly 
30 related systems. 

[0027] Figure 7 is a schematic diagram of the elec- 
tronic bill presentment and payment system shown in 
Figure 4, extended to include certain associated indi- 
rectly related systems. 
35 [0028] Figure 8 is a schematic diagram of the elec- 
tronic bill presentment and payment system shown in 
Figure 4, extended to include certain associated cus- 
tomer care entities. 

[0029] Figure 9 is a schematic diagram of the elec- 
40 tronic bill presentment and payment system shown in 
Figure 4, extended to include a centralized customer 
care entity. 

[0030] Figure 1 0 is af lowchart diagram showing initial 
sign-on data and message flows between a user entity 

45 and a banking entity in the electronic bill presentment 
and payment system shown in Figure 4. 
[0031] Figure 11 is a flowchart diagram showing sign- 
on and authentication data and message flows between 
a user entity, a banking entity, and an EPCS entity in the 

so electronic bill presentment and payment system shown 
in Figure 4. 

[0032] Figure 12 is a flowchart diagram showing bill 
availability data and message flows between a user en- 
tity, a banking entity, and an EPCS entity in the electron- 
55 ic bill presentment and payment system shown in Figure 
4. 

[0033] Figure 1 3A is a flowchart diagram showing bill- 
ing entity presentment data and message flows be- 
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tween a user entity, a billing entity, and an EPCS entity 
in the electronic bill presentment and payment system 
shown in Figure 4. 

[0034] Figure 1 3B is a flowchart diagram showing bill- 
ing aggregator bill presentment data and message flows 
between a user entity, a billing entity, an EPCS entity, 
and an established billing aggregator in the electronic 
bill presentment and payment system shown in Figure 4. 
[0035] Figure 1 3C is a flowchart diagram showing al- 
ternative system bill presentment data and message 
flows between a user entity, an EPCS entity, and an al- 
ternative bill presentment and payment system in the 
electronic bill presentment and payment system shown 
in Figure 4. 

[0036] Figure 14 is a flowchart diagram showing bill 
payment data and message flows between a user entity, 
an EPCS entity, and a billing entity in the electronic bill 
presentment and payment system shown in Figure 4. 
[0037] Figure 15 is a flowchart diagram showing bill 
remittance and debiting data and message flows be- 
tween an EPCS entity and a billing entity and a banking 
entity in the electronic bill presentment and payment 
system shown in Figure 4. 

[0038] Figure 16 shows an example of a branded in- 
terface having a sign-on request prompt that includes a 
username field and a password field. 
[0039] Figure 1 7 shows an example of a banking en- 
tity home page, including a "view bills" icon, a "view 
checking account" icon, and a "view savings account" 
icon. 

[0040] Figure 1 8 shows a first modified banking entity 
home page having a frame presenting new bill availa- 
bility data. 

[0041] Figure 19 shows a second modified banking 
entity home page having a frame presenting detailed bill 
data. 

[0042] Figure 20 is a flowchart diagram showing cus- 
tomer service data and message flows between a cen- 
tralized customer service center, and an EPCS entity, a 
billing entity, and a banking entity in the electronic bill 
presentment and payment system shown in Figure 4. 

DETAILED DESCRIPTION OF A PREFERRED 
EMBODIMENT 

[0043] Referring to Figure 3, there is shown an infra- 
structure diagram of a distributed database entity 30 in 
accordance with the present invention. The distributed 
database entity 30 comprises a database component 32 
and a plurality of message interfaces 34-40 for facilitat- 
ing communication between the database component 
32 and other distributed database entities and system 
components. The database component 32 typically con- 
tains data that is controlled or "owned" by the controller 
or "owner" of the distributed database entity 30. For ex- 
ample, if the distributed database entity 30 is owned by 
a financial institution (Fl) such as a bank, then the da- 
tabase component 32 could contain information such as 



checking and savings account balances. It should be 
noted, however, that the database component 32 can 
also contain data from other distributed database enti- 
ties and system components, as will be described in de- 
s tail below. 

[0044] The plurality of message interfaces 34-40 in- 
cludes an internal message interface 34, an external 
message interface 36, a partner message interface 38, 
and a customer care message interface 40. 
w [0045] The internal message interface 34 defines 
messages that are used to communicate and query data 
between the distributed database entity 30 and other 
distributed database entities, or other system compo- 
nents having an internal message interface. For exam- 
's pie, in a bill presentment and payment system, commu- 
nication between a banking entity and a billing entity 
may be required. 

[0046] The external message interface 36 defines 
messages that are used to communicate and query data 
20 between the given distributed database entity 30 and 
any existing system(s) that are directly related to the dis- 
tributed database entity 30. For example, an Fl such as 
a bank can have an existing direct deposit account 
(DDA) system. 

25 [0047] The partner message interface 38 defines 
messages that are used to communicate and query data 
between the distributed database entity 30 and any ex- 
isting system(s) that are indirectly related to the given 
distributed database entity 30. For example, in a bill pre- 

30 sentment and payment system, communication with an 
established billing aggregator may be necessary to sat- 
isfy customer demands. 

[0048] The customer care message interface 40 de- 
fines messages that are used to communicate and que- 

35 ry data between the given distributed database entity 30 
and a customer care entity. For example, in a bill pre- 
sentment and payment system, a billing entity may allow 
a third party to access bill data in order to provide feed- 
back to bill customers. 

40 [0049] It should be noted that all of the above-de- 
scribed interfaces will be described in greater detail be- 
low. 

[0050] Referring to Figure 4, there is shown a sche- 
matic diagram of a versatile electronic bill presentment 

45 and payment system 50 in accordance with the present 
invention. The system 50 includes a user entity 52, a 
banking entity 54, a billing entity 56, and an electronic 
payment and customer service (EPCS) entity 58. For 
purposes of this detailed description , each of entities 52 , 

so 54, 56 and 58 is similar to the distributed database entity 
30, as described above, but could, if desired, have only 
an internal message interface 34 so that communica- 
tions can take place between each entity. 
[0051] It should be noted that, although only a single 

55 user entity 52, banking entity 54, billing entity 56, and 
EPCS entity 58 are shown in the system 50, a plurality 
of each of these entities may exist in an actual versatile 
electronic bill presentment and payment system in ac- 
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cordance with the present invention. Since the entities 
52, 54, 56 and 58 are all distributed database entities, 
they all communicate through internal message inter- 
faces 34. These communications are performed over in- 
terconnections 60, which can be wire, optical fiber, or 
wireless interconnections. 

[0052] Each internal message interface 34, external 
message interface 36, partner message interface 38, 
and customer care message interface 40, can be imple- 
mented using any number of existing message-based 
communication systems such as, for example, a TCP/ 
IP message-based communication system running on 
the infrastructure of the internet. Alternatively, the inter- 
faces 34, 36, 38 and 40 could be implemented using 
proprietary messaging software on a private network or 
intranet. It should also be noted that there are no re- 
quirements as to the nature of the messaging protocol, 
or any middleware used to support the messaging. 

THE USER ENTITY 

[0053] The user entity 52 is typically a personal com- 
puter (PC) that is directly connected to the system 50, 
or is connected to the system 50 through a network serv- 
er (not shown). Thus, the database component 32 as- 
sociated with the user entity 52 can be located on the 
PC, e.g., a traditional "fat" client, or on the network serv- 
er, e.g., an HTML browser client. It should be noted that 
the database component 32 associated with the user 
entity 52 could, if desired, also be located in one or dis- 
tributed among all of the other distributed database en- 
tities, which can download data to the user entity 52, e. 
g., a Java client. Thus, each database component 32 
should not be thought of as a single, monolithic data- 
base. Rather, each database component 32 is better de- 
scribed as a distributed repository of data categorized 
by the entity that "owns" the data. 
[0054] Wherever it is located, the database compo- 
nent 32 associated with the user entity 52 stores data 
that is related to the type of user interface (Ul) that is 
being presented to a subscriber of the system 50. For 
example, the database component 32 associated with 
the user entity 52 can store data that is related to the 
particular type of presentation technology being used, 
e.g., a "fat" client, an HTML browser client, or a Java 
client, a specific application, or a particular version of an 
application. The database component 32 associated 
with the user entity 52 can also store data that is related 
to a particular computing session, such as the existence 
of a computing session and/or the duration of a comput- 
ing session, and subscriber authentication data, which 
is described in detail below. 

[0055] The main function of the user entity 52 is to 
build a Ul using data obtained from the other distributed 
database entities, and then present the Ul to a subscrib- 
er of the system 50. The presentation of the Ul to a sub- 
scriber is dependent upon the particular type of presen- 
tation technology being used, e.g., a "fat" client, an 



HTML browser client, or a Java client. For example, a 
Ul for a Java client requires that presentation data be 
downloaded from one of the other distributed database 
entities. 

5 [0056] Other functions of the user entity 52 include 
storing certain data locally so as to facilitate off-line ed- 
iting and viewing, maintaining a state in a connection- 
less environment, e.g., an HTTP environment, and 
sensing the availability of software updates and manag- 

io ing their subsequent application. All of these functions 
depend on the nature of the client, e.g., a "fat" client, an 
HTML browser client, or a Java client. Another function 
of the user entity 52 is storing subscriber authentication 
data, e.g., a security ticket that is used to gain access 

is to other distributed database entities in the system 50. 

THE BANKING ENTITY 

[0057] The banking entity 54, which is typically an Fl, 

20 such as a bank, is generally viewed as a primary point 
of contact for a subscriber to the system 50, typically 
providing an appearance of aggregation to the subscrib- 
er. This is primarily due to the trust that consumers typ- 
ically place in a bank brand, and the fact that bank cus- 

25 tomers who already bank online are also likely to want 
to receive bills online. Thus, in the following discussion, 
the banking entity 54 is assumed to be the aggregator 
of the system 50. It should be noted, however, that any 
one of the other entities could also be the aggregator of 

so the system 50 in accordance with the present invention. 
There are several factors which can be used to deter- 
mine aggregator status such as market clout. 
[0058] The banking entity 54 typically gains access to 
the system 50 through a network server (not shown). 

35 Thus, the database component 32 associated with the 
banking entity 54 can be located in the network server, 
but could also be located in a system associated with 
the banking entity 54, such as a DDA system. Such a 
DDA system could be accessed through the external 

to message interface 36 of the banking entity 54, as de- 
scribed in detail below. The database component 32 as- 
sociated with the banking entity 54 could, if desired, also 
be located in one, or be distributed among all, of the 
other distributed database entities. 

45 [0059] Wherever it is located, the database compo- 
nent 32 associated with the banking entity 54 stores 
bank-specific subscriber profile data profile such as, for 
example, subscriber names and addresses and sub- 
scriber account numbers. The database component 32 

so can also store account information, such as static ac- 
count information, e.g., lease rate, principle, and dy- 
namic account information, e.g., balance, and profile da- 
ta specifically associated with the Fl, such as graphics, 
business rules, banking-related transaction histories, 

55 and aggregation relationships, e.g. those between the 
Fl and billers. 

[0060] Since it is likely that the system 50 will be used 
with existing banking systems, such as an existing DDA 



5 



EP 1 136 923 



P a ge 6 of 3 8 



EP 1 136 923 A1 



10 



system, one of the main functions of the banking entity 
54 is the continuation of current banking and bill pay- 
ment functionality, including maintaining customer pro- 
files and already existing interfaces. In its role as aggre- 
gator, the banking entity 54 also provides data to the 
user entity 52 to be used for the creation of a navigation 
portion of a Ul. For an HTML browser client, this data 
would be used to create a navigation frame, but not a 
content specific frame. The banking entity 54 can also 
provide data to the user entity 52 to be used for the cre- 
ation of a Ul for traditional banking and bill payment. 
[0061 ] Since the ban king entity 54 is generally viewed 
as the primary point of contact for a subscriber to the 
system 50, the banking entity 54 also functions as the 
likely, but not exclusive, entry point for subscriber sign- 
on. Thus, the banking entity 54 typically controls the 
sign-on and authentication procedures for subscribers 
using the user entity 52. It should be noted that the bank- 
ing entity 54 typically works in conjunction with the 
EPCS entity 58 in controlling the authentication proce- 
dure, as described in detail below. 
[0062] Another function of the banking entity 54 in- 
cludes tracking bank related events and storing them in 
an event tracking database, which is typically associat- 
ed with the EPCS entity 58, as will also be described in 
detail below. 

THE BILLING ENTITY 

[0063] The billing entity 56 is commonly a biller such 
as, for example, a utility company. The billing entity 56 
typically gains access to the system 50 through a net- 
work server (not shown). Thus, the database compo- 
nent 32 associated with the billing entity 56 can be lo- 
cated in the network server. However, if desired, the da- 
tabase component could also be located in a system as- 
sociated with the billing entity 56, such as a legacy billing 
system, or in one or among all of the other distributed 
database entities. Such a legacy billing system could be 
accessed through the external message interface 36 of 
the billing entity 56, as described in detail below. 
[0064] Wherever it is located, the database compo- 
nent 32 associated with the billing entity 56 stores biller- 
specific subscriber profile data, such as subscriber 
names and addresses and subscriber account numbers 
and types, e.g., business vs. residential phone line. The 
database component 32 also stores billing data for use 
by the user entity 52 in building the Ul for the subscriber. 
The billing data can include bill availability data, detailed 
billing data, ads and other cross-sale displays and links, 
and bill payment terms and conditions. 
[0065] The database component 32 associated with 
the billing entity 56 can also store biller transaction his- 
tory, such as bill data manipulation, e.g., viewing, 
searching, and sorting, as well as cross-sell events. The 
database component 32 can further store biller profile 
data, such as graphics, business rules, and relation- 
ships with aggregators such as banks. 



[0066] The main function of the billing entity 56 is to 
provide billing data to the user entity 52 for use in cre- 
ating the Ul for the subscriber. The billing entity 56 also 
provides bill availability data to an aggregator database, 

s whether it is located in the banking entity 54, the EPCS 
entity 5B, or another entity, for use in providing notice of 
bill availability to subscribers. The billing entity 56 can 
also access legacy billing systems through the external 
message interface 36 of the billing entity 56, as indicated 

10 above. 

[0067] Another function of the billing entity 56 is track- 
ing biller-related events and storing them in an event 
tracking database, which is typically associated with the 
EPCS entity 58, as described in detail below. 

(5 

THE EPCS ENTITY 

[0068] The EPCS entity 58 can generally be de- 
scribed in terms of a data processing system 70, such 

20 as shown in Figure 5. The data processing system 70 
preferably includes at least one processor (P) 72, mem- 
ory (M) 74, and input/output (I/O) interface 76, which are 
connected to each other by a bus 78, for implementing 
the functions of the EPCS entity 58, as described in de- 

25 tail below. 

[0069] Referring again to Figure 4, the EPCS entity 
58 typically gains access to the system 50 through a net- 
work server (not shown). Thus, the database compo- 
nent 32 associated with the EPCS entity 58 can be lo- 

30 cated in the network server. However, if desired, the da- 
tabase component 32 associated with the EPCS entity 
58 can also be located in a system associated with the 
EPCS entity 58, such as a legacy aggregating system, 
or in one or among all of the other distributed database 

35 entities. Such a legacy aggregating system could be ac- 
cessed through the external message interface 36 of the 
EPCS entity 58, as described in detail below. 
[0070] Wherever it is located, the database compo- 
nent 32 associated with the EPCS entity 58 stores bill 

40 payment-specific subscriber profile data, such as sub- 
scriber names and addresses, subscriber DDA account 
numbers, and subscriber credit ratings. The database 
component 32 also stores bill payment warehouse data, 
such as user-specific payees, single occurrence pay- 

45 ments, and recurring payments/models. 

[0071] As previously described, both the banking en- 
tity 54 and the billing entity 56 track and store events in 
an event tracking database. This event tracking data- 
base is typically located in the database component 32 

so associated with the EPCS entity 58, and typically in- 
cludes event summaries and links to other databases, 
perhaps residing at other entities, which provide event 
details and/or an audit trail. 

[0072] The database component 32 associated with 
55 the EPCS entity 58 also stores bill payment transaction 
histories, and system subscriber profile data, such as 
metadata about subscribers and metadata about sub- 
scribers' relationships to other entities, e.g., a list of bill- 
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ers that a subscriber has enabled. The database com- 
ponent 32 further stores billing-related profile informa- 
tion on the system aggregator and billers, such as meta- 
data about billing arrangements, e.g., flat rate, per sub- 
scriber, event-driven, etc., and aggregation data, such 
as new bill availability and messages or special an- 
nouncements available from the billing entity 56. The 
database component 32 associated with the EPCS en- 
tity 58 may additionally store security data, such as re- 
quired sign-on information and macro-level authoriza- io 
tions, and customer service data, such as frequently 
asked questions (FAQ's), Fl and biller contact informa- 
tion, and problem resolution data. 
[0073] The EPCS entity 58 is the entity which ties the 
distributed database entities together. The EPCS entity « 
58 accomplishes this by functioning as an integration 
agent which maintains bill payment profiles and ware- 
house data, aggregates bill availability and status data, 
but not bill content or presentation, and maintains an 
event tracking database, i.e. an audit trail, that can be 20 
accessed by all of the database entities. Also, in order 
to facilitate a single point of sign-on, the EPCS entity 58 
functions as the authentication gate keeper. This is not 
intended to imply that the EPCS entity 58 necessarily 
maintains user identification numbers and/or pass- 25 
words. However, it does mean that the EPCS entity 58 
accepts sign-on requests and doles out authentication 
"tickets" in response thereto, in conjunction with the 
banking entity as described above. 

[0074] Like user identification numbers and pass- so 
words, other data elements, such as event details, may 
be aggregated at the EPCS entity 58, but may still phys- 
ically reside in a distributed manner across several of 
the database entities. The EPCS entity 58 may also 
route e-mail messages to and from the various database 35 
entities, as well as store e-mail messages sent to and 
from the various database entities. 

INTERNAL MESSAGE PROCESSING 

40 

[0075] The following types of messages are examples 
of messages which may be employed to implement an 
internal message interface 34 in accordance with the 
present invention. The message specification or file for- 
mat can be either standard, i.e., open, or special, i.e. « 
proprietary. 

USER ENTITY INTERNAL MESSAGE PROCESSING 

[0076] Depending upon the nature of the presentation so 
technology being used, e.g., a "fat" client, an HTML 
browser client, or a Java client, the user entity 52 may 
need to process an internal message to store a security 
ticket for later use in gaining access to other distributed 
database entities in the system 50, and/or to update any ss 
resident software. The user entity 52 may also need to 
process an internal message containing various types 
of information (assuming a push model), and/or internal 



e-mail messages, such as those for receiving data from 
other database entities. 

BANKING ENTITY, INTERNAL MESSAGE 



[0077] The banking entity 54 will process an internal 
message to add/update/delete/retrieve Fl branding in- 
formation, and to add/update/delete an entry from a list 
of billers that have been aggregated. The banking entity 
54 will also process an internal message to activate a 
subscriber for home banking via a messaging protocol, 
which can be an existing messaging protocol, such as 
OFX, ora batch process, and to query/update bank sub- 
scriber profile data for purposes of customer care. The 
banking entity 54 will further process an internal mes- 
sage to query banktransaction history for customer care 
and for linking to the event tracking database, and to 
retrieve a list of billers available under the Fl sponsor 
umbrella or to place the list of billers available under the 
Fl sponsor umbrella in an aggregation database. Plac- 
ing the list of billers available under the Fl sponsor um- 
brella allows the EPCS entity 58 to tailor the list by Fl 
sponsor. 

[0078] The banking entity 54 will additionally process 
internal e-mail messagessuch as those for sending data 
to other database entities, receiving data from other da- 
tabase entities, and broadcasting data to other data- 
base entities. 

BILLING ENTITY INTERNAL MESSAGE 
PROCESSING 

[0079] The billing entity 56 will process an internal 
message to add/update/delete/retrieve biller branding 
information, and to activate a subscriber for electronic 
bill presentment via a messaging protocol, which can be 
an existing messaging protocol, for example OFX, or a 
batch process. The billing entity 56 will also process an 
internal message to retrieve bill availability data, retrieve 
bill detail data, and retrieve bill presentation specifica- 
tions or content. The retrieved data could, for example, 
be URL links to ads and notices, HTML data, or OFX 
data. 

[0080] The billing entity 56 will also process an inter- 
nal message to query/update billersubscriber profile da- 
ta for purposes of customer care, and to query biller 
transaction history for customer care and for linking to 
the eventtracking database. The billing entity 56 will ad- 
ditionally process internal e-mail messages, such as 
those for sending data to other database entities, receiv- 
ing data from other database entities, and broadcasting 
data to other database entities. 

EPCS INTERNAL MESSAGE PROCESSING 

[0081] The EPCS entity 58 will process internal event 
tracking messages used to gain access to two types of 



5 PROCESSING 



35 



40 



45 



7 



EP 1 136 92 3 



Pa ge 8 of 38 



13 EP 1 136 923 A1 14 



information in the event tracking database: summary 
data and a link to another database entry that can pro- 
vide more detail, such as subscriber enrollment data, 
subscriber service activation data, e.g., biller, bill pay- 
ment, banking, etc., sign-on data, bill availability data, 
bill viewed data, bill payment generated data which is 
optionally associated with presented bill data, subse- 
quent bill payment events data, e.g., submitted, proc- 
essed, failed, cleared, remittance received by biller, etc., 
cross-sell events data, e.g., ad/offer viewed, ad/offer 
clicked, product/service purchased, terms & conditions 
viewed data, and e-mail created/read/deleted data. 
[0082] The EPCS entity 58 will also process internal 
messages related to subscriber profile data, such as to 
add/modify/delete/read subscriber profile data, often as 
a function of the events listed above, e.g., enrollment, 
activation, etc. 

[0083] The EPCS entity 58 will additionally process 
internal security messages. Such internal security mes- 
sages may relate to authentication, which result in the 
EPCS entity 58 issuing a security ticket. It should be not- 
ed that an authentication request does not have to be 
received as a result of a subscriber directly contacting 
the banking entity 54, but may be initiated if a subscriber 
attempts to gain access to the billing entity 56, without 
contacting the banking entity 54. The point being that 
with a security ticket a subscriber is generally allowed 
to freely traverse any database entity in the system 50 
without going through repeated sign-on procedures. 
[0084] An internal security message may relate to 
macro-level authorization, resulting in issuance of a se- 
curity ticket that includes credentials allowing a sub- 
scriber access to a particular billing entity, without ad- 
dressing micro-level authorization issues such as the 
operations the subscriber will be allowed to perform. 
[0085] An internal security message may also result 
in issuance of a security ticket without authentication. 
Such a message will originate from a trusted party, e.g., 
an Fl performing its own authentication. 
[0086] It should be noted that the use of a security 
ticket enables, but does not mandate, a single sign-on 
procedure. In other words, a database entity, such as 
the billing entity 56, may, for whatever reason, require 
additional authentication information. 
[0087] The EPCS entity 58 will further process inter- 
nal messages relating to aggregation data. For exam- 
ple, an EPCS entity 58 will process an internal message 
to create a link to summary or detailed bill information, 
or to create a link to message, notice, ad, or some other 
kind of non-bill information that is available from the bill- 
ing entity 56. 

[0088] Furthermore, the EPCS entity 58 will process 
an internal message to query/update bill payment trans- 
action history for purposes of customer care. The EPCS 
entity 58 will process internal e-mail messages, such as 
those associated with routing e-mail, picking-up e-mail, 
and querying an e-mail mailbox. The EPCS entity 58 
may also process internal messages related to data 



mining. Such messages are handled very carefully to 
ensure privacy, perhaps even providing an ACL or other 
mechanisms to ensure privacy. The results of such mes- 
sages may be delivered out of band, e.g., by batch. 

5 

EXTERNAL MESSAGE PROCESSING 

[0089] Referring to Figure 6, there is shown a sche- 
matic diagram of the versatile electronic bill present- 

10 ment and payment system 50, along with certain asso- 
ciated directly related systems. The directly related sys- 
tems includes a desktop database 80, a DDA system 
82, a legacy billing system 84, and a legacy remittance 
system 86. The communications between the various 

15 database entities and their associated directly related 
systems are performed over interconnections 88, which 
can be wire, optical fiber, or wireless based interconnec- 
tions. The message specification or file format can be 
either standard, i.e., open, or special, i.e. proprietary. 

20 

USER ENTITY, EXTERNAL MESSAGE PROCESSING 

[0090] Depending upon the nature of the presentation 
technology being used, e.g., a "fat" client, an HTML 

25 browser client, or a Java client, the user entity 52 may 
need to process an external message in order to com- 
municate with a related system, such as the desktop da- 
tabase 80. To support a system, it may be necessary to 
implement the external message interface 36 of the user 

30 entity 52 using an existing, and possibly extended, pro- 
tocol specification, such as Gold, NPC, or OFX, as will 
be understood by those skilled in the art. 

BANKING ENTITY EXTERNAL MESSAGE 
35 PROCESSING 

[0091] The banking entity 54 will process external 
messages to and from a related system, such as the 
DDA system 82, in order to query and update informa- 
40 tion, for example subscriber profile data, subscriber ac- 
count data, out-of-band (e.g., ATM) account activity and 
statement history. It may also be desirable for the bank- 
ing entity 54 to interface with other banking systems (e. 
g., stops). 

45 

BILLING ENTITY EXTERNAL MESSAGE 
PROCESSING 

[0092] The billing entity 56 will process external mes- 
so sages to and from related systems, such as the legacy 
billing system 84, in order to query and update informa- 
tion, for example subscriber profile data, subscriber ac- 
count data, account activity and statement history. Most 
of this data is industry, if not biller, specific. 

55 

EPCS EXTERNAL MESSAGE PROCESSING 
[0093] The EPCS entity 58 will process external mes- 
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sages to and from related systems, such as the legacy 
remittance system 86. The legacy remittance system 86 
could, for example, be an ACH, RPP, RPS, or Direct 
Send, as will be well understood by those skilled in the 
art. 

PARTNER MESSAGE PROCESSING 

[0094] Referring to Figure 7, there is shown a sche- 
matic diagram of the versatile electronic bill present- 
ment and payment system 50, along with some associ- 
ated indirectly related systems. The indirectly related 
systems includes a personal finance system 90, a bank- 
ing system 92, an established billing aggregator 94, and 
an alternative bill presentment and payment system 96. 
The communications between the various database en- 
tities and the indirectly related systems are performed 
over interconnections 98, which can be wire, optical fib- 
er, or wireless interconnections. The message specifi- 
cation or file format can be either standard, i.e., open, 
or special, i.e. proprietary. 

USER ENTITY PARTNER MESSAGE PROCESSING 

[0095] Depending upon the nature of the presentation 
technology being used, e.g., a "fat" client, an HTML 
browser client, or a Java client, the user entity 52 may 
need to process a partner message in order to commu- 
nicate with a partner, such as the personal finance sys- 
tem 90. The personal finance system 90 could, for ex- 
ample, be a personal financial manager (PFM) software 
package such as Quicken (TM) or Money (TM). 

BANKING ENTITY PARTNER MESSAGE 
PROCESSING 

[0096] The banking entity 54 will process partner 
messages to and from a partner, such as the banking 
system 92. 

BILLING ENTITY PARTNER MESSAGE 
PROCESSING 

[0097] The billing entity 56 will process partner mes- 
sages to and from a partner, such as the established 
billing aggregator 94. Such a partner relationship may 
be required if a large group of subscribers are using the 
established billing aggregator 94, and thereby have the 
leverage to demand that all of their bills be communicat- 
ed through the established billing aggregator 94. 
[0098] The established billing aggregator 94 is essen- 
tially treated as a proxy for the billers that it represents. 
Thus, subscribers to the system 50 through the estab- 
lished billing aggregator 94 are treated in thesame man- 
ner as direct subscribers to the system 50. This means 
that subscribers to the established billing aggregator 94 
will receive the same event tracking, customer service, 
and payment processing functionality as direct sub- 



16 

scribers to system 50. 

[0099] To present a bill generated by the established 
billing aggregator 94 the system 50 may, for example, 
receive bill availability data and the URL of a web server 

5 of the established billing aggregator 94. The billing entity 
56 stores detailed bill data on the web server of the es- 
tablished billing aggregator 94 so that subscribers may 
obtain an HTML presentation of detailed bill data from 
the aggregator bill server. In this scenario, the partner 

10 message interface 38 would be essentially the same as 
an internal message interface 34, but could, if desired, 
have added bulk transfer capability. 

EPCS PARTNER MESSAGE PROCESSING 

[0100] The EPCS entity 58 will process partner mes- 
sages to and from a partner, such as the alternative bill 
presentment and payment system 96. Such a partner 
relationship may be required if a billing entity 56 has a 
20 subscriber base that includes both subscribers to the 
system 50 and subscribers to the alternative bill present- 
ment and payment system 96. 

[0101] In such a case, the system 50 could function 
as a billing aggregator for the alternative bill present- 

25 ment and payment system 96, or vice-versa. The alter- 
native bill presentment and payment system 96 and its 
subscribers might not receive any of the benefits of the 
messaging functionality provided by the present system 
50. Only limited functionality might be provided. That is, 

30 the partner message interface 38 might only provide the 
functionally required to present bills through the alter- 
native bill presentment and payment system 96. As will 
be recognized by those skilled in the art, the EPCS entity 
58 will typically require capabilities of a billing entity 56 

35 in order to present bills to and from the alternative bill 
presentment and payment system 96. 

CUSTOMER CARE MESSAGE PROCESSING 

40 [0102] Referring to Figure 8, there is shown a sche- 
matic diagram of the versatile electronic bill present- 
ment and payment system 50, along with certain asso- 
ciated customer care entities. The customer care enti- 
ties include a user entity self service center 1 00, a bank- 

4S ing entity customer service center 102, a billing entity 
customer service center 104, and an EPCS customer 
service center 106. The communications between the 
various database entities and their associated customer 
care entities are performed over interconnections 108, 

so which can be wire, optical fiber, or wireless interconnec- 
tions. The message specification or file format can be 
either standard, i.e., open, or special, i.e. proprietary. 

USER ENTITY CUSTOMER CARE MESSAGE 
55 PROCESSING 

[01 03] Depending upon the nature of the presentation 
technology being used, e.g., a "fat" client, an HTML 
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browser client, or a Java client, the user entity 52 may 
need to process a customer care message in order to 
communicate with a customer care entity, such as the 
user entity self service center 100. The user entity self 
service center 1 00 could, for example, be a self service 
diagnostic tool. 

BANKING ENTITY CUSTOMER CARE MESSAGE 
PROCESSING 

[0104] The banking entity 54 will process customer 
care messages from a customer care entity, such as the 
banking entity customer service center 1 02. A customer 
care message may be a request for data or a request to 
modify existing data. Such customer care messages are 
processed by providing the requested data or providing 
a confirmation that the existing data has been modified 
to the banking entity customer service center 1 02. The 
banking entity customer service center 102 could, for 
example, be a third party telemarketing group that is al- 
lowed access to banking and overall system data in or- 
der to provide feedback to system subscribers. 

BILLING ENTITY CUSTOMER CARE MESSAGE 
PROCESSING 

[0105] The billing entity 56 will process customer care 
messages from a customer care entity, such as the bill- 
ing entity customer service center 1 04. A customer care 
message may be a request for data or a request to mod- 
ify existing data. Such messages are processed by pro- 
viding the requested data or providing a confirmation 
that the existing data has been modified to the billing 
entity customer service center 104. The billing entity 
customer service center 1 04 could, for example, be a 
third party telemarketing group that is allowed access to 
billing and overall system data in order to provide feed- 
back to system subscribers. 

EPCS CUSTOMER CARE MESSAGE PROCESSING 

[01 06] The EPCS entity 58 will process customer care 
messages from a customer care entity, such as the 
EPCS entity customer service center 106. A customer 
care message may be a request for data or a request to 
modify existing data. Such messages are processed by 
providing the requested data or providing a confirmation 
that the existing data has been modified to the EPCS 
entity customer service center 106. The EPCS entity 
customer service center 106 could, for example, be a 
third party telemarketing group that is allowed access to 
event and overall system data in order to provide feed- 
back to system subscribers. 

[0107] It should be noted that all of the customer care 
entities described above could, if desired, be consoli- 
dated into a centralized customer service center 1 1 0, as 
shown in Figure 9. In such a case, each of the database 
entities would process customer care messages to and 
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from the centralized customer service center 110 in a 
manner similar to that described above. Communica- 
tions between the various database entities and the cen- 
tralized customer service center 110 would be per- 
5 formed over interconnections 112, which may be wire, 
optical fiber, or wireless interconnections. 

MESSAGE FLOW 

10 [0108] Referring to Figures 10-15, there are shown 
flowchart diagrams of data and message flows between 
the various entities within the system 50. These flow- 
chart diagrams assume that the user entity 52 is an 
HTML browser client, the banking entity 54 is the prima- 

'5 ry point of presence for a subscriber to the system 50, 
the billing entity 56 controls bill presentment, and the 
EPCS entity 58 controls bill payment. 
[0109] In Figure 10, a subscriber at the user entity 52 
accesses the web site of the banking entity 54 in step 

20 200. In return, the banking entity 54 presents a branded 
interface to the user entity 52, including a sign-on re- 
quest prompt in step 202. Figure 16 shows an example 
of such a branded interface 120, wherein the sign-on 
request prompt includes a username field 122 and a 

25 password field 124. 

[0110] In Figure 11, the user entity 52 submits a sign- 
on request with authentication credentials in steps 204. 
The banking entity 54 messages the EPCS entity 58 
with the authentication credentials of the subscriber and 

30 the event is logged in step 206. The EPCS entity 58 pro- 
vides a security ticket to the banking entity 54 in step 
208. The banking entity 54 delivers the security ticket to 
the user entity 52 and presents its "home page" to user 
entity 52 in step 210. Figure 17 shows an example of 

35 such a home page 1 30, which includes a "view bills" icon 
132, a "view checking account" icon 134, and a "view 
savings account" icon 136. 

[0111] It should be noted that either the EPCS entity 
58 or the banking entity 54 could perform the authenti- 
40 cation procedure. In either case the event is logged in 
the event tracking database. 

[0112] In Figure 12, the subscriber selects the "view 
bills" icon 132 in step 212. The banking entity 54 mes- 
sages the EPCS entity 58 with an aggregation data re- 
45 quest and the event is logged in step 214. The EPCS 
entity 58 presents aggregation data of bill availability to 
user entity 52 in step 21 6. 

[0113] Figure 18 shows a modified home page 140 
having an EPCS entity frame 142 presenting the bill 

so availability data, which includes an "electric bill" icon 
144, a "gas bill" icon 146, a "phone bill" icon 148, a "ca- 
ble bill" icon 150, a "credit card bill" icon 1 52, and an "all 
bills" icon 154 which allows all bills to be presented si- 
multaneously, albeit in separate frames. 

55 [0114] In Figure 13A, the subscriber selects the "gas 
bill" icon 146 and is linked to the billing entity 56. The 
security ticket is transmitted in step 218. The billing en- 
tity 56 messages the EPCS entity 58 to log the "view 
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bill" request event in step 220. The billing entity 56 
presents detailed bill data to the user entity 52 in step 
222. 

[0115] Figure 1 9 shows another modified home page 
160 having a billing entity frame 162 presenting the de- 
tailed bill data, .which includes the subscriber name, 
subscriber address, account number, usage, and cost, 
and a "pay bill" icon 164. 

[0116] In Figure 14, the subscriber selects the "pay 
bill" icon 164 and messages the EPCS entity 58 with a 
forward dated pay bill request. The event is logged in 
step 224. The EPCS entity 58 messages the billing en- 
tity 56 with a pay bill request notification along with a bill 
identification number in step 226. 
[0117] In Figure 15, the EPCS posts a debit with the 
banking entity 54, and the event is logged in step 228. 
The EPCS entity 58 then remits a paymentto the billing 
entity 56 and the event is logged in step 230. 
[0118] Figure 13B can be substituted for Figure 13A 
in the above-described sequence of flowchart diagrams 
if detailed bill data is provided by the established billing 
aggregator 94 thru the partner message interface 38 of 
the billing entity 56. As shown, the subscriber again se- 
lects the "gas bill" icon 146 and is linked to the billing 
entity 56. The security ticket is transmitted in step 232. 
The billing entity 56 again messages the EPCS entity 
58 to log the "view bill" request event in step 234. How- 
ever, in this case, detailed bill data is available only from 
the established billing aggregator 94. Thus, the billing 
entity 56 accesses the established billing aggregator 94 
through its partner message interface 38 in step 236. In 
response, the established billing aggregator 94 provides 
detailed bill data to the billing entity 56 in step 238. The 
billing entity 56 then presents the detailed bill data to the 
user entity 52 in step 240. 

[0119] It should be noted that, if desired, the estab- 
lished billing aggregator 94 could present the detailed 
bill data directly to the user entity 52. 
[0120] Figure 13C can be substituted for Figure 13A 
in the above-described sequence of flowchart diagrams 
if detailed bill data is provided by the alternative bill pre- 
sentment and payment system 96 thru the partner mes- 
sage interface 38 of the EPCS entity 58. As shown, the 
subscriber selects the "gas bill" icon 146 and is linked 
back to the EPCS entity 58. The security ticket is trans- 
mitted and the event is logged in step 242. 
[0121] In this case, detailed bill data is available only 
from the alternative bill presentment and payment sys- 
tem 96. Thus, the EPCS entity 58 accesses the alterna- 
tive bill presentment and payment system 96 through its 
partner message interface 38 in step 244. In response, 
the alternative bill presentment and payment system 96 
provides detailed bill data to the EPCS entity 58 in step 
246. The EPCS entity 58 then presents the detailed bill 
data to the user entity 52 in step 248. 
[0122] Alternatively, detailed bill data could, if desired, 
be provided by the alternative bill presentment and pay- 
ment system 96 thru the partner message interface 38 



20 

of the billing entity 56 in a manner similar to that as de- 
scribed in Figure 13B. 

[0123] Referring to Figure 20, there is shown a flow- 
chart diagram of data and message flows between the 

5 centralized customer service center 1 1 0 and the various 
entities within the system 50. A subscriber 1 70 contacts 
the centralized customer service center 110 regarding 
a bill payment in step 250. The centralized customer 
service center 1 1 0 accesses the event tracking data- 

10 base in the EPCS entity 58 to see if a view bill, pay bill, 
remit payment, or debit posting event has been logged 
in step 252. If more detailed information regarding, for 
example, the posting of a debit for a bill is required, the 
centralized customer service center 1 1 0 can access the 

'5 database component 32 associated with the banking 
entity 54, as shown in step 254. Similarly, if more de- 
tailed information regarding, for example, the remitting 
of a payment for a bill is required, the centralized cus- 
tomer service center 1 1 0 can access the database com- 

20 ponent 32 associated with the billing entity 56, as shown 
in step 256. Although not shown, the EPCS entity 58 
can log all of the above-described accesses performed 
by centralized customer service center 110. 
[0124] As is apparent from the foregoing description, 

25 the system 50 allows a subscriber to interact directly 
with individual billers while retaining the benefits of in- 
teracting with a single aggregator, such as a single au- 
thentication and log-in procedure and a common bill 
presentation framework. The system 50 also allows a 

30 subscriber to interact with a single aggregator while al- 
lowing the billers and banks to retain control of subscrib- 
er-related data and a communication channel with each 
subscriber. 

[0125] The present invention is not to be limited in 
35 scope by the specific embodiments described herein. 
Indeed, various modifications of the present invention 
in addition to those described herein, will be apparent 
to those of skill in the art from the foregoing description 
and accompanying drawings. Thus, such modifications 
40 are intended to fall within the scope of the appended 
claims. 



Claims 

45 

1. A method for centrally tracking transactions in an 
electronic billing system having multiple different 
billing entities, multiple different financial institute 
entities and multiple different user entities, each of 

so the multiple different billing entities being associat- 
ed with a respective portion of the multiple different 
user entities and each of the multiple different finan- 
cial institute entities being associated with a respec- 
tive portion of the multiple different user entities, 

55 comprising the steps of: 

receiving, from any of the multiple different fi- 
nancial institute entities, a message indicative 
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of a request from any of the multiple different 
user entities associated'with the applicable fi- 
nancial institute entity to view billing informa- 
tion; 

logging, in a database, the receipt of the re- 
quest to view the billing information as a first 
event information; 

transmitting, to the applicable user entity, a 
message indicative of the billing information of 
at least one of the multiple different billing enti- 
ties associated with the applicable user entity 
which is available for viewing; 
receiving, from any of the at least one of the 
billing entities, a message indicative of a re- 
quest from the applicable userentityto view the 
available billing information of that billing entity; 
and 

logging, in the database, the receipt of the mes- 
sage indicative of the applicable user entity re- 
quest to view the billing information of the ap- 
plicable billing entity as a second event infor- 
mation. 

2. A method according to claim 1 , further comprising 
the steps of: 

receiving a message indicative of a signing-on 
to the system of the applicable user entity; and 
logging, in a database, the receipt of the mes- 
sage indicative of the applicable user entity 
signing-on to the system. 

3. A method according to claim 2, wherein the mes- 
sage indicative of the applicable user entity signing- 
on to the system is indicative of the applicable user 
entity having been authenticated. 

4. A method according to claim 2, wherein the mes- 
sage indicative of the applicable user entity signing- 
on to the system is received, from the applicable 
financial institute entity, and includes authentication 
credentials of the applicable user entity. 

5. A method according to claim 1 , wherein the at least 
one of the billing entities is two or more billing enti- 
ties, and further comprising the steps of: 

receiving, from the applicable user entity, a re- 
quest to view the available billing information of 
another of the two or more billing entities; 
logging, in the database, the receipt of the ap- 
plicable user request to view the available bill- 
ing information of the other applicable billing 
entity; and 

transmitting, to the applicable user entity, the 
requested billing information of the other appli- 
cable billing entity. 
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6. A method according to claim 1 , further comprising 
the steps of: 

receiving, from the applicable user entity, a re- 
s quest to pay a billed amount represented by the 

billing information which the applicable user en- 
tity has requested to view; and 
logging, in the database, the receipt of the ap- 
plicable user request to pay the billed amount 
io as a third event information. 

7. A method according to claim 6, further comprising 
the steps of: 

15 transmitting, to the applicable financial institute 

entity, arequesttodebitthebilledamountfrom 
an account maintained by the applicable finan- 
cial institute entity on behalf of the applicable 
user entity; 

20 logging, in the database, the request to debit 

funds associated with the account maintained 
by the applicable financial institute entity on be- 
half of the applicable user entity as a fourth 
event information; 

25 transmitting, to applicable billing entity, a pay- 

ment of the billed amount; and 
logging, in the database, the payment of the 
billed amount as a fifth event information. 

30 8. A method according to claim 7, further comprising 
the steps of: 

receiving, from a customer care representative 
of at least one of the applicable financial insti- 
35 tute entity and the applicable billing entity, a re- 

quest for one or more of the first, the second, 
the third, the fourth and the fifth event informa- 
tion; 

retrieving the requested one or more of the first, 
40 the second, the third, the fourth and the fifth 

event information from the database; and 
transmitting the retrieved information to the 
customer care representative. 

45 g. A system for centrally tracking electronic billing 
transactions involving multiple different billing enti- 
ties, multiple different financial institute entities and 
multiple different user entities, each of the multiple 
different billing entities being associated with a re- 

so spective portion of the multiple different user enti- 
ties and each of the multiple different financial insti- 
tute entities being associated with a respective por- 
tion of the multiple different user entities, compris- 

a processor configured (i) to receive, from any 
of the multiple different financial institute enti- 
ties, a message indicative of a request from any 
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of the multiple different user entities associated 
with the applicable financial institute entity to 
view billing information, (ii) to transmit, to the 
applicable user entity, a message indicative of 
the billing information of at least one of the mul- 
tiple different billing entities associated with the 
applicable user entity which is available for 
viewing, (iii) and to receive, from any of the at 
least one of the billing entities, a message in- 
dicative of a request from the applicable user 
entity to view the available billing information of 
that billing entity; and 

a database configured to store a log of the re- 
ceipt of the request to view the billing informa- 
tion as a first event information, and of the 
ceipt of the message indicative of the applica- 
ble user entity request to view the billing infor- 
mation of the applicable billing entity as a sec- 
ond event information. 

10. A system according to claim 9, wherein: 

the processor is further configured to receive a 
message indicative of a signing-on to the sys- 
tem of the applicable user entity; and 
the database is further configured to store a log 
of the receipt of the message indicative of the 
applicable user entity signing-on to the system. 

11. A system according to claim 10, wherein the mes- 
sage indicative of the applicable user entity signing- 
on to the system is received from the applicable fi- 
nancial institute entity. 

12. A system according to claim 9, wherein: 

the at least one of the billing entities is two or 
more billing entities; 

the processor is further configured to receive, 
from the applicable user entity, a request to 
view the available billing information of another 
of the two or more billing entities and to trans- 
mit, to the applicable user entity, the requested 
billing information of the other applicable billing 
entity; and 

the database is further configured to store a log 
of the receipt of the applicable user request to 
view the available billing information of the oth- 
er applicable billing entity. 

13. A system according to claim 9, wherein: 

the processor is further configured to receive, 
from the applicable user entity, a request to pay 
a billed amount represented by the billing infor- 
mation which the applicable user entity has re- 
quested to view; and 

the database is further configured to store a log 



of the receipt of the applicable user request to 
pay the billed amount as a third event informa- 



s 14. A system according to claim 13, wherein: 

the processor is further configured to transmit, 
to the applicable financial institute entity, a re- 
quest to debit the billed amount from an ac- 
10 count maintained by the applicable financial in- 

stitute entity on behalf of the applicable user en- 
tity, and to transmit, to applicable billing entity, 
a payment of the billed amount; and 
the database is further configured to store a log 
15 of the request to debit funds associated with the 

account maintained by the applicable financial 
institute entity on behalf of the applicable user 
entity as a fourth event information, and of the 
payment of the billed amount as a fifth event 
20 information. 

15. A system according to claim 14, wherein: 
the processor is further configured (i) to re- 
ceive, from a customer care representative of at 
least one of the applicable financial institute entity 
and the applicable billing entity, a request for one or 
more of the first, the second, the third, the fourth 
and the fifth event information, (ii) to retrieve the re- 
quested one or more of the first, the second, the 
third, the fourth and the fifth event information from 
the database, and (iii) to transmit the retrieved in- 
formation to the customer care representative. 

16. A method for centrally tracking electronic billing 
transactions between multiple different billing enti- 
ties and multiple different user entities, each of the 
multiple different billing entities being associated 
with a different portion of the multiple different user 
entities, comprising the steps of: 

receiving requests at the multiple different bill- 
ing entities from the multiple different user en- 
tities to view billing information; and 
storing an indication of the receipt of the re- 
quests in a central database as first event in- 
formation. 

1 7. A method according to claim 1 6, further comprising 
the steps of: 

receiving requests from the multiple different 
user entities to pay billed amounts represented 
by the requested billing information; 
storing an indication of receipt of the requests 
from the multiple different user entities to pay 
the billed amounts in the central database as 
second event information; 
receiving requests to debit the billed amounts 
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from accounts maintained on behalf of the mul- 
tiple different user entities by multiple different 
financial institute entities, each being associat- 
ed with a respective portion of the multiple dif- 
ferent user entities; 

storing an indication of receipt of the requests 
to debit the billed amounts from the accounts 
in the central database as third event informa- 
tion; 

directing payments of the billed amounts; and 
storing an indication of the payments in the cen- 
e as fourth event information. 



18. A method according to claim 17, further comprising 
the steps of: 

receiving requests at the multiple different fi- 
nancial institute entities from the multiple differ- 
ent user entities to view billing information; and 
storing an indication of the receipt of requests 
at the multiple different financial institute enti- 
ties from the multiple different user entities to 
view billing information in the central database 
as fifth event information. 

19. A method according to claim 17, further comprising 
the steps of: 

receiving, from a customer care representative 
of at least one of the multiple different financial 
institute entities and the multiple different billing 
entities, a request for one or more of the first, 
the second, the third, and the fourth event in- 
formation; 

retrieving the requested one or more of the first, 
the second, the third, and the fourth event in- 
formation from the central database; and 
transmitting the retrieved information to the 
customer care representative. 

20. A method according to claim 1 6, further comprising 
the steps of: 

transmitting messages to the multiple differ- 
ent user entities, each respective message indica- 
tive of the billing information of the multiple different 
billing entities which is available to a particular one 
of the multiple different user entities for viewing. 

21. A system for centrally tracking electronic billing 
transactions between multiple different billing enti- 
ties and multiple different user entities, each of the 
multiple different billing entities being associated 
with a different portion of the multiple different user 
entities, comprising: 

a central database configured to store transac- 
tion events; and 

a central processor configured to log, in the da- 



tabase, requests received by the multiple dif- 
ferent billing entities from the multiple different 
user entities to view billing information as first 
event information. 

22. A system according to claim 21 , wherein: 

the central processor is further configured to 
log, in the database, (i) requests from the multiple 
different user entities to pay billed amounts repre- 

to sented by the requested billing information as sec- 
ond event information, (ii) requests to debit the 
billed amounts from accounts maintained on behalf 
of the multiple different user entities by multiple dif- 
ferent financial institute entities, each being associ- 

'5 ated with a respective portion of the multiple differ- 
ent user entities as third event information, and (iii) 
payments of the billed amounts as fourth event in- 
formation. 

20 23. A system according to claim 22, wherein: 

the central processor is further configured to 
log, in the 

database, requests received by the multiple dif- 
25 ferent financial 

institute entities from the multiple different user 
entities to 

view billing information. 

so 24. A system according to claim 22, wherein the central 
processor is further configured (i) to receive, from 
a customer care representative of at least one of 
the multiple different financial institute entities and 
the multiple different billing entities, a request for 

35 one or more of the first, the second, the third, and 
the fourth event information, (ii) to retrieve the re- 
quested one or more of the first, the second, the 
third, and the fourth event information from the da- 
tabase, and (iv) to transmit the retrieved information 

40 to the customer care representative. 

25. A system according to claim 21 , wherein the central 
processor is further configured to transmit messag- 
es to the multiple different user entities, each re- 
spective message indicative of the billing informa- 
tion of the multiple different billing entities which is 
available to a particular one of the multiple different 
user entities for viewing. 
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